asciilifeform: http://btcbase.org/log/2017-12-26#1758779 << i see e.g. trb tree, as the frayed end of a rope. in long term, observe, the loose ends that dun get built on -- fade away, like orphan chains. btc is actually more or less same kind of system. but iirc we had this thread.
asciilifeform: which, in the whole picture, does not come close to topping the list of the hardest labours of a trb experimenter
asciilifeform: i can't speak for others, but asciilifeform often ( almost always, in fact ) runs trb during tests, in pure userland, making use of 0 systemwide loggings )
asciilifeform: what i'd like to see is 'was it from a trb?'
asciilifeform: that already printed ( the latter , in classical trb, mutilated )
asciilifeform: exactly like what an unpatched trb does for first hour or three of boot
asciilifeform: well right nao it's pulling blox from other trb's, at ~100% efficiency
asciilifeform: ... as mircea_popescu prolly intuited , it remains possible that 'aggression' takes the trb<->prb link breakage from , say, the 80% of before, to 100% , and i would not learn about it until reaching tip.
asciilifeform: it did take a while to reach this state, given as 'wires' are no longer in use. had to actually connect to a working and nonblackholed trb.
asciilifeform: this is testable empirically; like-so: any N trb nodes built with 'aggression' patch above, and linked via 'wires', should never fall out of height-sync with one another by more than a coupla blox. at any point.
asciilifeform: *where any 2 trb nodes connect, and...
asciilifeform: analysis so far : ^^item^^ results , at last , in situation where any 2 trb nodes, and 1 is 'ahead' of the other, the 'trailing' node is guaranteed to be fed.
asciilifeform: !~later tell trinque where didja get the log-timestamps in your trb ? ( which patch pressed to ? )
asciilifeform: shinohai: trb needs a disk
asciilifeform: anybody got 2 trb-capable boxen, on separate ip but equal in bw ? can be in heathendom isp or wherever.
asciilifeform: and speaking of hasty and untested , asciilifeform has a 'aggressive sync mode' trb patch, which will need a proper differential test
asciilifeform: as i understood trb historically was 'and here is bitcoin minus the post-2011 barnacles, deviate at your own risk, derps, it will still be there an' working'
asciilifeform: ideally reference-trb is capable-of-everything, incl. cpumining ( see the dozen or so threads at this point )
BingoBoingo: <asciilifeform> all i can say is, to date only observed db death on boxes with actual bit rot. << Aha, saw when trying to start trb from blockchain loaded onto box from corrupted thumb drive
BingoBoingo: Once trb gets enough network speed to work, extra doesn't offer much
BingoBoingo can't recall running a trbtron I could touch on a connection faster than 3 mbps until in Montevideo
asciilifeform: mircea_popescu: should hope so. because 100mb ain't enuff for even 1 trbtron
asciilifeform: trinque: the 1 common thread in asciilifeform's lab notes from birth of trb to today, is that once they fall behind, they stay behind, until reset. (often more than one reset.)
asciilifeform: aside from brief period at bootup, a trb node DOES NOT TRY TO SYNC AT ALL, passively waits for someone to come and feed it. forever.
asciilifeform: quite heavy compared to even, say, trb.
asciilifeform: btw some very large share of 'no can haz trb, plz help' in the logs to date, feature shituntu
asciilifeform: pretty sure that mod6 hosts a curl, at trb www
asciilifeform: fact is, trb sync is ragingly retarded. as in , microshit-level.
asciilifeform contemplates placing trb on ramdisk on this box
asciilifeform: but the results ( at least in asciilifeform's torture room ) have been disappointing, currently afaik nobody even knows why bdb ignores locks knob ( perma-hosing trb ) !! under bsd
asciilifeform: and 4G typically suffices to run trb 'year-round'.
asciilifeform: btw asciilifeform will reveal that he found a 'new' (to him) and very spiffy type of amd g-series box , suitable for trb and similar
asciilifeform trying very different tack re 'trbi' than in prev thread, instead of massive warcrime , series of small gedankenexperiment.
asciilifeform: this gedankenexperiment should be seen in light of the earlier 'all tx have absolute position and make references to absolutepositional outputs' item from earlier 'trbi' thread.
asciilifeform: nominally libc doesn't go in a gnat-baked elf, so it isn't quite the same urgency as musltronic gcc-for-trb was
asciilifeform: ( trb-genesis, for better or worse, was a plain cut of the original material. ended up preserving the idiocy of empty file. )
asciilifeform: where the linkage was ~not~ mechanically clear, because it appeared merely as a set of external symbols inside trb, rather than a proper lift of the files
asciilifeform: diana_coman: pretty sure it is same as mod6 has on trb www
asciilifeform: interestingly , this item was the 2nd thing asciilifeform ever genesised ( http://therealbitcoin.org/ml/btc-dev/2015-October/000175.html ) . 1st was trb.
BingoBoingo: Well, when discussing trb on Openbsd we are talking something that spans 5.5-ish and ends no later than 6.1
asciilifeform: ( aside from some obsolete matter on trb ml )
asciilifeform: asciilifeform is also in the process of standing up trb on dulap-III , an opteron monster not yet homed.
asciilifeform: also notably, mircea_popescu , yer trb box was the champ medallist, outlived even dulap.
asciilifeform: btw mircea_popescu re 46.166.160.36 / http://thebitcoin.foundation/trusted-nodes.html : is that box still around ? because if it is, yer trb is hung
asciilifeform: but will note that, e.g., trb, builds cleanly on e.g. arm ( and iirc ppc also )
asciilifeform: or could be >0, depending on whether e.g. having trb around, is worth +
asciilifeform: all trb boxen where log wasn't cut off, have day-by-day, neh
asciilifeform: ( getting this number from a trbtron is still a manual process. )
asciilifeform: spyked: musl however worx great, trb stands on it. and iirc trinque has an entire musltronic gentoo.
asciilifeform: http://thebitcoin.foundation/trb-howto.html << grep for gcc
asciilifeform: you can produce this mechanically. the unfortunate bit is that it gives same problem as basing trb on original 5.3.1 tarball contents did
asciilifeform: and it's a perfectly legit ( manually ground, from mpi, just like trb genesis was from 0.5.3 ) genesis.
asciilifeform: hey i still to this day use jurov's system, whenever submitting trb patch.
asciilifeform: same way we avoid gavinization of trb, for instance.
asciilifeform: if yer disk is too small to rotate debug.log by hand 1-2x/year, it is too small to run trb !!
asciilifeform does not currently have even 1 up-to-top trb node !
BingoBoingo: Seems to be where a lot of TRB nodes are shown stalled.
asciilifeform: sooner turn pig into a professor of mathematics, than cpp trb into sanity.
asciilifeform: how would trb pay a 3, lol
asciilifeform: hey trinque check your boxes that had 'wires', they are probably STILL running, and trbing to it
asciilifeform: in other lulz, something closely resembling trb node on ex-dulap ( 46.166.165.30 ) still running... though i do not recommend it for any practical use
asciilifeform: mircea_popescu: is it working as intended, or is the result trb-like ( 'life support patient' ) ?
asciilifeform: like trb! ( but i'ma not repeat, because at this point everybody knows )
asciilifeform: ahhahaha exactlylike trb
asciilifeform: ugh sounds like trb
asciilifeform: ./v.pl p v trb54 makefiles.vpatch <<< is the answer
asciilifeform: ( btw is it clear that buildroot is only part of the trb universe because we dun have a musltronic linux to do ordinary stator builds in ? )
asciilifeform: and iirc we also had thread re how crapple is not in business because asciilifeform reads trb coad and 1970s 'химия и жизнь' on a crappad
asciilifeform: ( remember, an unsynced trb node rejects ~ALL tx )
asciilifeform: ^ asciilifeform's very painstaking 'trbfication' of koch
asciilifeform: diana_coman: and in your trb wot dir likewise.
BingoBoingo: <mircea_popescu> teh network is disrupted to all hell fwiw. << On the plus side, most of the public facing trb identified nodes are back caught up to sync
asciilifeform: http://btcbase.org/log/2017-09-14#1714258 << funkenstein was an odd d00d: shat on trb, but lifted it wholesale for use in his altwhatever; today hangs in kakolandia and misses no chance to hurrdurrmpisafraud etc
asciilifeform: and so long all trb nodes ?
asciilifeform: 1) move the btc using trb, to new addr 2) import (now empty on btc chain) privkey into shitcoin node 3) empty the shitcoins into a gox 4) sell
asciilifeform: move the btc using a trb node
asciilifeform: http://btcbase.org/log/2017-09-10#1711819 << prb wasn't involved here, was operating on trb .dat's
BingoBoingo: http://btcbase.org/log/2017-09-01#1708137 << Until they try to run a node... Syncing TRB far less painful that keeping up with Ethereum...
asciilifeform: a trb node that's perpetually months (or yearz) behind topheight, mainly sits around rejecting tx all day long
asciilifeform: because even in whole 1G i never saw trb live for >week
asciilifeform: how long your longest run of trb on pogo, danielpbarron ?
asciilifeform: it is why i work on, e.g., trb, despite having scarcely any coin personally.
asciilifeform: probably never yet seen trb, either...
asciilifeform: stock trb dun help much
asciilifeform: the reason why mike_c's node appears 'stalled' is that it stopped fetching blocks. trb's block sync behaviour is unspeakably moronic, it will attempt 'long sync' ONCE, on warmup
asciilifeform: if trb node is not fetching blocks, but is not showing symptoms of 'black hole'
asciilifeform: !~later tell mike_c http://btcbase.org/log/2017-08-23#1702508 << this is NORMAL behaviour for a trb node. and see below re 'stalls' :
asciilifeform: mircea_popescu: hilariously wrong description of trb
BingoBoingo: <mircea_popescu> i mean, a trb capable machine is somewhere in the 50-100 bux / month range, certainly an expense but not the end of the world. << Negrodamus, i.e. 192.187.99.74 rents for less
asciilifeform: http://btcbase.org/log/2017-08-22#1702394 << it is zoolag, it is resyncing, and ( i assume everybody knows ) it is ~impossible to usefully connect to a trb node that is syncing
asciilifeform: spyked: trb is very long way from 'sane object' but otherwise yes.
asciilifeform: i use it in workstations. but the cost is imho misplaced in a trb node, which are supposed to be a redundancy layer p2pfully in themselves !
asciilifeform: pete_dushenski: as i understand it's a couplea line patch to trb
asciilifeform: !~later tell ben_vulpes was it you who had a trb patch abolishing the idiotic truncation of block and tx hashes in debug.log ? where did it go ?
asciilifeform: i don't much like the phrase 'trusted nodes', when you connect to trb node, you get plaintext tcp, and 0 guarantees re who or what you're actually talking to.
asciilifeform: !~later tell mike_c http://btcbase.org/log/2017-08-19#1700623 << why was it necessary to use closed turd client ? ( what's the actual diff in the lolfork anyway ? the 2mb thing ? could exist as a lulzpatch for trb, even, in principle )
asciilifeform: ACHTUNG panzers!! trb node 'zoolag' is back in business, this time as ordinary linux box -- syncing from 0 . same ip as prev.
asciilifeform: mike_c: congrats on building trb, incidentally
asciilifeform: other idea is to demonstrate that trb can work without riding on top of existing telecom structure.
asciilifeform: also interesting to mike_c will be the 'trbi' threads..
asciilifeform: the index won't read by trb.
asciilifeform: also i thought mention of mp/trb/et al were a hangin' offense at tardstalk
asciilifeform: and there's a history of trb nodes of various types perma-wedging there
asciilifeform: this thing behaves precisely like trb sans locks patch, i think
asciilifeform: i dun think it is anything to do with that tx per se -- it is the drop that overflowed the barrel in pre-dblockspatch trb
asciilifeform: until this 'not' remains, trb ain't a program, it's a voodoo incantation.
asciilifeform: naively thought 'i'll start with the smallest trb node!'
BingoBoingo: last sync test WAS trb on linux
asciilifeform: trb on linux : does
asciilifeform attempts a build of traditional stator trb inside netbsd ( as rotor is unnecessary there, there is no drepper glibc )
asciilifeform: ( no trb yet, but enough to re-pour the cement... )
asciilifeform: well i have. currently, by expecting 1 fewer trb testbed..
asciilifeform: trb in 256M ain't happening.
asciilifeform: extra infuriating detail -- i dun specifically need x86 for this , trb runs ok on arm. BUT all extant arms have soldered down (and insufficient) ram.
asciilifeform: btw in case this wasn't clear, this was zoolag , which did 2+ yrs of 24/7 trb.
asciilifeform: and this is true of pretty much any box that makes decent trb node (i.e. has sata3 + ssd )
asciilifeform: ( and in fact it ran on my pogo. but that doesn't produce a usable trb node. )
asciilifeform: not sure how that goes directly with trb
asciilifeform: also lol re the attempted theft of the name 'trb'/'the real bitcoin'
asciilifeform: for clarity : asciilifeform ain't inluvv with superH. but he ~does~ search for a cpu where 1) respectable (say, even trb-capable) horse 2) no internal flash rom 3) not ARM
asciilifeform: in other noose!, a samsung ssd lasts about 2y in a high-traffic trb node.
BingoBoingo: <asciilifeform> ... though i can see what mircea_popescu means. prb would not, iirc, eat a highS block. and several other types that trb happily eats. << PRB will eat high S when in block. Will fail to propagate high S until mined.
asciilifeform: ... though i can see what mircea_popescu means. prb would not, iirc, eat a highS block. and several other types that trb happily eats.
BingoBoingo: Holy fuck we are about as close to TMSR Wagon as we were to TRB in 2013 given all this engine talk
asciilifeform: interestingly asciilifeform recently learned that the 'mutate high to low S and broadcast malleated tx but ONLY if a 'doublespend attempt' ( you retransmitting, say, with patched trb ) is detected ' thing is STILL running
asciilifeform: it is a problem in the same way as it is for trb.
BingoBoingo: <lobbes> damn. looks like my plans for my old craptop being a trb node will have to wait until I secure better iron. << Why can old craptop not eat SSD?
BingoBoingo: badD00d: TRB now WILL accept segwit blocks, but it will not parse the segwit'd portion as anything other than "anyone can spend"
BingoBoingo: TRB will continue accepting valid blocks
asciilifeform: nothing observable to ~people~ -- i.e. folx using trb -- yes. to redditus running gavincoin etc - thermonukokalypse
asciilifeform: phf: imho sampling profilers are a wholly useless thing, 'horse with pedals', unless you're working a honeywagon (e.g. virginal trb) and have deeply nfi what the hell the program is doing
asciilifeform: afaik deedbot is currently the only thing auto-signing ( inside its tx-issuing trb )
asciilifeform: hey, they gotta keep inmat^H^H^H^H^Hstudents from hosting warez/trb/etc terrorisms somehow!1111
asciilifeform: it will have to be confiscated from the monkeys, like trb was.
asciilifeform: what trb item have you tested, IamAGirlsoInever ?
asciilifeform: unrelatedly, i have nfi who trb node 208.94.240.42 belongs to, but it's been stuck in the 300,000s for ~ages~
asciilifeform: meanwhile, in the world of sad prototypes : asciilifeform discovered ( and why did it have to be ' asciilifeform discovered ...' when other folx were nominally also testing...) that trb node with 'wires' still happily falls behind by 100s of blox, and never catches up,
asciilifeform: at one time he grudgingly tested some trb
asciilifeform: reference trb gotta keep working, uninterrupted,
asciilifeform: idea , however, is that it will run blox past trad trb ( netless , mempoolless trb ) as 'final court'
asciilifeform: hence why all of asciilifeform's trb work from month or so ago and forever more, is about losing the cpp hairball.
asciilifeform: it syncs when hits a fellow trb by accident and that's mostly it.
asciilifeform: if you believe the heathen chart ('bitnodes'), 'falcon' mega-relay-network etc has ~same number of nodes as... their count of trb.
asciilifeform: achtung, panzers! anyone who noticed that his trb wire to dulap dropped last night -- the thing was rebooted (without my permission) ~13 hours ago.
asciilifeform: and lol , mircea_popescu's lament is ~exactly asciilifeform's ~yearly 'when i stop writing trb fixes, they stop getting written'...
asciilifeform: ( before mircea_popescu balks -- 'trbi' ain't btc )
asciilifeform: it resembles trb 'wires' .
asciilifeform: glibc is also not supported for trb.
asciilifeform: for trb, that is.
asciilifeform: y'know, when trb sits like idiot and waits for bdb to disk i/o.
asciilifeform: ^ all but the last is mostly wasted on trb
asciilifeform: today - 'trb-i', ciphers of known strength, a few others.
BingoBoingo: pete_dushenski: When do we get G5 trb sync stats?
asciilifeform: i find it slightly outrageous that i have a pressed aluminum ratheadlinux from 1990s but not a pressed aluminum gcc4.9 or trb-genesis etc
asciilifeform: i propose a declaration of 'tx replacement is an attack against sane bitcoin and whoever does it, is the forker, and not us, who thereafter ban it in trb and subsequent proggies.'
asciilifeform: let's say we find that, e.g., gcc past 3.x embeds an off-by-one-ization in memcpy() , dependant on payload, and that it is triggerable specifically in trb tx processing.
asciilifeform: i have plenty of 'c machines' right here that cannot run trb (on account of 'too small addr space' or 'too slow clock', take your pick.)
asciilifeform: at any rate this is a bizarre line of thought. trb (or rather, bitcoin, the existing network) has any kind of long term future ~strictly~ if it can be entirely separated from the cpp abortion.
asciilifeform: trb (the currently existing item) could quite conceivably run on entirely different type of machine, under emulation (smbx , for instance, shipped... believe -- a c compiler, in genera. along with fortran, ada..)
asciilifeform: ( this also ignores the -- screamingly evident -- fact of trb being ~algorithmically~ defective. as explored on several occasions here. )
asciilifeform: do what you will to trb, it is still written in idiot language that does not check bounds, on idiot iron that does not check bounds.
asciilifeform: builds static trb, bootable initrd+kernel, busybox userland, ~5MB (littleendian arm) package all in all.
asciilifeform: theoretically trb & prb permit 'tx replacement' idiocy
asciilifeform: ( possibly -- if some hero devotes several years to it, trb-style -- but even then )
asciilifeform: 'Hello asciilifeform I see on coin.dance/nodes , The Real Bitcoin is listed with the 'Emergent Consensus' feature tag. Could you tell me if that's accurate - will you follow a HF to > 1MB , and could you tell me anything about how it's implemented in TRB ? Thx!'
asciilifeform: the other open seekrit re classical trb : and afaik applies equally to various prbs : there is no means whereby to introduce a martian reorg consisting of >1 block, such that it will actually get processed.
asciilifeform: ( reorg in trb is also ~ruinously~ expensive )
asciilifeform: classical trb simply throws those out, as malformed rubbish in ProcessBlock()
asciilifeform: http://btcbase.org/log/2017-03-26#1632698 << zero instances in my trb logs to date, mp_en_viaje
asciilifeform: say, for instance, kako's 'trb is broken, won't push my p2sholade'
asciilifeform: iirc prb doesn't even maintain a socket with trb , starting with 11 or so
asciilifeform: also what patch set do you use, TomServo ? my trb doesn't have time stamps, for instance.
asciilifeform: ( and you couldn't put, e.g., trb in there. )
asciilifeform: ben_vulpes: http://therealbitcoin.org/ml/btc-dev/2015-January/000033.html << arm cross-flags example (from ye olde trb)
asciilifeform: bulldozer that amplifies my intelligence and makes such thing as, e.g., unravelling trb, possible, is not 'balcony tomato'.
asciilifeform: ( anyone here tried trb on bigendian ? i -- have not )
asciilifeform: http://btcbase.org/log/2017-03-20#1629232 << trbi, with the fixed-length-everythings, needs ~no fancy indexer at all. it's for a hypothetical sane-trb.
asciilifeform: davout: per current trb rules (which , see earlier, is different from prb's ! even) A gotta be spent before it can reappear.
asciilifeform: if you can re-introduce an old coinbase -- which you can , if it has been spent, per trb rules -- you (or anyone else) can afterwards reintroduce any and all tx that had that coinbase as an input
asciilifeform: trb, i will note, already will not relay any attempt to spend anything not already in a block.
asciilifeform: ^ this is a question that can be answered exactly , using a patched trb
asciilifeform: it would instead manifest as one or more chains of tx that a trb node -- a particular one, that saw the particular magic orphan -- mysteriously does not want to spend the outputs of.
asciilifeform: now for the practical consequence. what this means, as far as i can tell, is that there can exist -- may already exist -- chains of tx in trb, that cannot be walked back to a coinbase.
asciilifeform: trb as it exists , permits a new tx having same hash as old, so long as old one was spent.
asciilifeform: 50* was spent, and per trb rules, garbagecollected from the index
asciilifeform: as i understand, it will validate, in trb.
asciilifeform: sooo per my reckoning, you can have sane-trb-indexer, but now every tx gotta have a field for 'was replaced?' -- and if bit is set, indexer goes and looks at the collision table, the previous lookup now 'didn't count'
asciilifeform: also it is not clear to me that trb ever... worked, in the customary sense of the word. what, for instance, happens if you actually carry out the -- entirely legal per all known btctrons -- replacement of a ~spent~ coinbase tx ?
asciilifeform: but possibly now mircea_popescu sees what asciilifeform meant by 'trbi is much EASIER problem than working-trb'
asciilifeform: and i don't mean trb
asciilifeform: this is not an original discovery, there's a magic case for it in trb
asciilifeform: mircea_popescu: 90% of the retardation of trb is that objects live in heap and are all part of a massive ball of yarn, linked to one another
asciilifeform: that thing also runs various housekeeping systems, aside from trb. like a champ.
asciilifeform: sorta the point of trb.
asciilifeform: accepts a block that ye olde trb wouldn'tve
asciilifeform: Framedragger: at the risk of repeating old thread : there is no way to 'replace bitcoin with trbi'. it isn't a thing that can be done.
asciilifeform: ACHTUNG, panzers! ben_vulpes , trinque : trb node at dulap will be unavailable for next ~hour .
asciilifeform: if i had a ticket to the mythical planet where programmers aren't retarded and 'the shame of poverty' is not smelled, we would not even be having the trb conversation.
asciilifeform: trinque: don't put wire-trb on your icbm-controller box. the skull is there for a reason.
asciilifeform: and you aint backing up 'this box' but the trb deps. that got frozen 4evah.
asciilifeform: mircea_popescu: now all you gotta do is to move the subdir 'bitcoin' inside this 'trbfoo' to replace the 'bitcoin' dir in trb54
asciilifeform: mircea_popescu: you pasted the .gitignore from inside the resulting dir 'trbfoo' ? make sure this was so ?
asciilifeform: ./v.pl p v trbfoo asciilifeform_wires_rev1.vpatch
asciilifeform: rm -rf trb54
asciilifeform: ( which iirc mircea_popescu and also hanbot successfully used to build trb )
asciilifeform: your copy of this turd (quite unnecessary in trb, in fact, but that's besides the point, we inherited it in genesis) consists of the original concatenated to itself !
asciilifeform: ./v.pl p v trb54 asciilifeform_wires_rev1.vpatch
asciilifeform: that's where all of the patches from which trb is made, live.
asciilifeform: see mod6's document, step '0x09) `mkdir patches` Gather trb vpatches from http://thebitcoin.foundation/v/patches in which ever manner suits you best.'
asciilifeform: this presupposes that you have a trb+wires built
asciilifeform: mircea_popescu: i was attempting a nonretarded trb-fs.
asciilifeform: unrelatedly, i have combed trb src for a cap on tx input and output maxima, and found none
asciilifeform: mircea_popescu: unrelatedly, didja ever calculate what would happen to trb (or for that matter prb) if one were to produce a colliding txid ?
asciilifeform: seems like a shit idea tho. 'oops there isn't a trb running on dulap, because ooops i broke the build'
asciilifeform: without gutting and replacing the entire logic of trb.
asciilifeform: sooo mircea_popescu , to revisit upstack , the entire doublespendpreventer mechanism in trb relies on this nonsense , http://btc.yt/lxr/satoshi/source/src/main.cpp?v=makefiles#0855 << is where it marks spent, and http://btc.yt/lxr/satoshi/source/src/main.cpp?v=makefiles#0847 is the doublespendtrap
asciilifeform: if trb is in a state of snake tongue, ALL of the affected tx do not belong in the index table
asciilifeform: meanwhile, opened the binder of horrors, with trb src, and found some lulz, which is actually what i sat down at the terminal to share:
asciilifeform: the other fundamental problem, and the reason why asciilifeform's interest in recycling old fs for trb is ~0, is that imho trb needs LESS dependency on open sores crud, rather than moar
asciilifeform: phf: you're quite right that it isn't. thing is an astonishing pile of gnarl. but all of the necessary info, is ~inside~ it, just like 'bitcoin' lives inside the rubbish of trb
asciilifeform: i contemplate it as more of a 'demolition charge', when trbi exists.
asciilifeform: trb will not even need to know whether it was given a real disk, or flat file.
asciilifeform: much cheaper to reindex a trb node, what, 1 night, than for enemy to bake new asics.
asciilifeform: (i would hope that l1 will last until trbi..)
asciilifeform: if you start seeing them ~regularly~ (say, trb makes it to 50 yrs from nao) you put in a l2 table.
asciilifeform: imho the 'hard part' is not even to implement this table, it is freshman homework, but to unravel the liquishit in trb and learn where to even put the lookup/write !
asciilifeform: i was recently considering implementing a similar scheme for phuctor, and realized today that it would work entirely well in trb.
asciilifeform: if you want to consider 'what would give best performance on the iron we have, with minimal moving parts, with the trb we have' this is what comes out.
asciilifeform: so in practice, you can have O(1) seeks ~while~ storing the blocks back-to-back in a classical trb.
asciilifeform: this form will almost certainly suffice for another decade of trb
asciilifeform: the Right Thing would probably be to have a very simple kernel driver that takes a specially-marked disk partition and gives userland trb linear use of it, as plain array
asciilifeform: who the fuck wants trb running as root
asciilifeform: it exists (wallet idiocy aside) in trb for 1 purpose and 1 purpose only
asciilifeform: let's put down in the log, what exactly ye olde bdb does, that eats 99+% of trb's wall clock:
asciilifeform: if you gotta actually break compatibility with ext4 and write new kernelspace driver -- may as well design proper (b-tree) fs for trb.
asciilifeform: mircea_popescu: since we're on subj of 'trbi', i was hoping to see the thread continue, re whether mempools, or whether my particular, or some other, scheme for abolition of mempool can be made to work , and so forth
asciilifeform: i oughta be quite specific re : 'nobody wants'. say i write a trbi, along one of the described schemes. nao wat -- mircea_popescu mines it ? and after this, who will want it ? 'just another premined alt!111' etc.
asciilifeform: the thing that cools asciilifeform's enthusiasm re 'trbi' to somewhere south of 3 kelvin, is that it isn't clear to him that anybody actually wants this, for something
asciilifeform: but this find is applicable, sadly, ~only~ to trbi
asciilifeform: it is interesting how much, imho, moar readable these are, than trb.
asciilifeform: ( incidentally, trb doesn't validate scripts in blocks. at. all. )